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REMARKS 

Claims 1 to 6, 8 to 13, 15 to 19, 24, 26 to 31, 33 to 38, 
and 40 to 42 were pending in the application at. the time of the 
final examination- Claims 1, 12, 13, 15, 24, 26, 37, 38, and 
40 to were objected to for informalities. Claims 1 to 6, 8 to 
13, 15 to 19, 24, 26 to 31, 33 to 38, and 40 to 42 Stand 
rejected as obvious. 

Claims 1, 12, 13, 24, 26, 37, 38, and 40 have been amended 
to correct the informality noted by the Examiner- Applicants 
respectfully request reconsideration and withdrawal of the 
objection to each of Claims i, 12, 13, 24, 26, 37, 38, and 40. 

Applicants respectfully request entry of the amendments to 
the claims. The amendments correct a typographical error and 
so entry does not require consideration of new issues or a new 
search. In view of the following remarks, Applicants 
respectfully submit that entry is proper under Rule 116 because 
the amendments place the application in condition for 
allowance. If the Examiner should disagree, entry is requested 
to narrow the issues for appeal. 

Claims 1 to 6, 8 to 13, 15 to 19, 24, 26 to 31, 33 to 38, 
and 40 to 42 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent Wo- 6,829,770, hereinafter 
referred to as Hinson, in view of U.S. Patent No. 6,694,506, 
hereinafter referred to as LeBlanc and Admitted Prior 
Arts (APA) . 

Applicants respectfully traverse the obviousness 
rejections of Claims 1, 26 and 40 ► To make a prima facie 
obviousness rejection, the MPEP directs: 

BASIC CONSIDERATIONS WHICH APPLY TO OBVIOUSNESS REJECTIONS 

When applying 35 U.S. C. 103, the following tenets of 
patent law mmust be adhered to: 

(A) The claimed invention must be considered as a whole; 

(B) The references must be considered as a whole and must 
suggest the desirability and thus the obviousness of 
making the combination,- 
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(C) The references must be viewed without the benefit of 
impermissible hindsight vision afforded by; the claimed 
invention; and 

(D) Reasonable expectation of success is the standard with 
which obviousness is determined. 



MPEP § 2141, 8th Ed., Rev. 3, p. 2100-125 (August 2005). It is 
noted that this directive stated "the following* tenets . . . 
ittust be adhered to . " Accordingly, the failure of the Examiner 
to adhere to any one of these tenets means that a prima facie 
obviousness rejection has not been made. 

The final rejection failed to adhere to multiple of these 
tenets and so a prima facie obviousness rejection has not been 
made. As demonstrated more completely below, the claimed 
invention has not been considered as a whole; the references 
have not been considered as a whole; and the references do not 
suggest the desirability of making the combination. Pieces of 
the references have been extracted and selectively interpreted 
in view of Appellants' claims. Finally, there was no 
explanation of how the primary reference would work for its 
intended purpose following the modification. 

In the rejection of Claim 1, the Examiner first stated in 
part: . • 

... an event (provides an event class object to 
distribute information produced by a publisher to one or 
more subscribers, lines 41-43 column 11) ii;i a object 
facility repository (142, Fig. 7 ) ■ • 

the event having an event type (to .subscribe to a 
particular outgoing event interface method'. . ., lines 
40-53, column 13; the type of object to be retrieved from 
the event objects store 140, lines 60-61 column 16 , . . 



creating an event object for the event (event object 
102, Fig. 5; event objects within the storage 142, Fig. 
7) , the event object corresponding to the event sub- type 
(class of the event objects having methods,, line 8-41 
column 12) ; 
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Final Office Action dated 07/12/2006, pages 2 and 3. 

Applicants respecttully note that these Claims recite "an 
event" and "the event, "so that one event is being recited in 
the claim. Nevertheless, the rejection considers the claim 
piecemeal and cites to multiple different partsj of Hinson with 
respect to this event. ' 

First the rejection cites to Col. 16, lines 60 and 61 as 
defining the event typei However, when Hinson is considered as 
a whole, i.e.. Col. 16, * lines 60 and 61 are taken in context, 
Hinson taught : . 

FIGS, 21-31 are program listings 230-241 of various 
interfaces defined; per the COM+ Events system . The se 
system-defined interfaces are exposed by various system- 
provided objects, as well as by the publisher 102 and 
subscriber 106 objects written by the application 
developer or other . user of the illustratedl event 
communications model 100 (FIG. 5) for integration into the 
model. I 

The program listing 230 of FIG. 21 defines an 
IBvent System interface that is exposed by the CQM+ Events 
system 140 (FIG, 7) , The lEventSystem interface includes 
the methods, "Query ( ) , " "Store ( ) , " "Remove ( ) , " and 
"EventObjectChangeEventClassID( )." The "Store ( )" method 
is used to install , objects into the event objects store 
142 (FIG. 7), such. as the piiblisher 104 an^ the event 
class 102 supporting the pxiblisher's outgoing- event 
interface (as demonstrated in the program listing 164 of 
FIG. 13 of the Stock Exchsmge application example) , as 
well as the subscriptions 12 0 (as demonstrated in the 
program listing 192 of FIG. 19) , 

The "Query( )'? method is used to retrieve objects 
from the event objects store 140 . The method takes two 
input parameters ("ProgID" and "wszQueryCriteria" ) and two 
output parameters ( "errorlndex" and "pplnterf ace") . The 
"ProgXD" parameter I identifies the type of object to be 
retrieved from the i event objects store 140 & The valid type 
values that can be; specified in this parameter are listed 
in the header file statements shown in thelprogram listing 
242 of FIG. 32. (Emphasis Added. Bold Emphasis is 
portion cited in rejection) . 
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Thus, the rejection 
"ob j ects . " Further , Hineon 
values of "ProglD" are 



@020 



EverxtPublisher 



. PROGID_ 
* PROGID_Bventp, 

PROGID__Event Syibcr ip t ion 



lass 



PROGID Event 
PRGGID 



EventClassCollect 



These are objects in the 



|i 



confuses "an event type" with 

expressly stated! that the valid 
in Fig. 32. Fig, 32 defines 



r: 



lisherCollection 



ion 



PROGlD_Event Sub s Crip t ionCol 1 ec t i on 



COM Event System 140 of Hinson, This 



fails to provide any teaching or suggestion of "the event 



an event sub - type / " as recited in 



having an event type and 
these claims . 

The rejection, in &ljie next recitation of event type and 
event sv±>-type in these I claims / reduced the claim language to a 
gist as quoted above ^ "creating an event object; for the event." 
The claims do not recite creating an event object just for some 

event but rather a specific event, "the event* object 

'I 

corresponding to the event sub- type." The eyent types 
initially cited in the rejection do not have jsufetypes and so 
the rejection switches focus to event object 102, i.e., the 



on the location in the, claim, 
rejection, the event sub-type is 
event objects having methods, line 8- 



definition changes based 
In this part of the 
reduced to "class of the 

:i 

41 column 12." Again, at best, a general gist is being 
rejected. The event object is described by Hinson as "The 
event class object 102 thus is a system- supplied object." The 
rejection has failed to c:ite any teaching or 'suggestion in the 
cited portion of Hinson of a sub-type of an event type for th© 
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event. Ixx particular, there is no citation to a suggestion or 
teaching in Hinson of sub-typing a particular event type based 
on the methods included in the event. The only basis for this 
is Applicants' claims language. j 
The rejection further stated in part: i 

Hinson does not explicitly teach tlae object facility 
repository is a meta object facility repository. However, 
Hinson teaches (lines 50-57 column 7) tliat. the invention 
can be implemented in combination with other program 
modules that implement particular abstract data types. 
Therefore one of ordinary skill in the art. could conclude 
that the particular abstract data type could be metadata 
defining the structure of data objects and; the object 
facility repository of Hinson could be a m^ta object 
facility repository. 

This statement mischaracterizes the reference, 
mischaracterizes abstract data type, mischaracterized metadata, 
and fails to consider Hinson as a whole yet again. There is no 
citation to any reference with respect to the level of skill in 
the art interpreting abstract data type or metaciata. 
Therefore, the conclusory statement concemirig What one of 
skill in the art could conclude after reading "Abstract data 
types" is not supported by any prior art teaching. 

An abstract data type is not interpreted by those of skill 

in the art as a type of data as inferred in t:his part of the 

rejection. Hinson stated: [ 

! 

Generally, pz-ogram loodules include jroutines, 
programs, con^onents, data structures,, etcl that perform 
particular tasks or inclement particular abstract: data 
types j 

! 

Thus, Hinson taught program modules incl|ude elements that 
implement abstract data types. An implementation of an 
abstract data type is needed because an abstract data type is 
■'A set of data values and associated operaticjns that are 
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precisely specified independent of any particular 
implementation." Paul E. Blacky "abstract data. type", in 
Dictionary of Algorithms and Stzructures [online], Paul E- 
Black, ed. , U.S. National Institute of Standards and 
Technology^ 10 February 2005 • Available froiA: i 
http : /www. nist. gov/ dads /HTML/abstactDataType^html. A copy of 
this docximent is included as Attachment 1. iippiicants note 
that the date of this document is after the filing date of the 
above application. However, the definition ijg consistent with 
that used by those of skill in the art and ttie liise of the term 
in Hinson. Accordingly, to the extent that dhe rejection 
infers that Hinson is describing a type of data, the rejection 
is inconsistent with the level of skill in the art. 

Further, the specification defines "Metadata is 
information about data, or simply data about data." 
Accordingly, when the level of skill in the art ; is considered 
it is error to equate metadata with abstract data type as was 
done in the rejection and further, there is rio iasis other than 
Examiner argument to support the conclusion ais noted above. 

Next, Hinson in context taught: 

Exemplary Operating Environment 

PIG- 1 and the following discussion are intended to 
provide a brief, general description of a suitable 
computing environment in which the invention may be 
implemented- While the invention will be| described in the 
general context of computer- executable ijnstructions of a 
computer program that runs on a computer], those skilled in 
the art will recognize that the invention also may be 
implemented in combination with other prbgram modules. 
Generally, program modules include routines., programs, 
components, data structures, etc. that perform particular 
tasks or implement particular abstract dsata types. 

Thus, the "other modules" are those in ah operating 
system- Hinson makes this clear by stating; 
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With reference now to FIG. 4, the computer 20 (FIG. 
1) executes componeint applications that [are developed as a 
package of component application objects. In the 
illustrated embodiriient of the invention] the conponent 
application objects conform to the Microsoft Component 
Object Model ("COM'j) specification (i.eJ, are implemented 
as a "COM Object" fio') and executed usindf the COM+ services 
of the Microsoft Windows NT Server 5.0 operating system as 
stated above, but alternatively may be implemented 
according to other" object standards (including the CORBA 
(Common Object Reqiieist Broker ArchiteGtijre]j specification 
of the Object Management Group) and exe(;2uted \mder object 
services of anotheaj operating system. Thle COM 
specification defines binary standards for. objects and 
their interfaces which facilitate the iiitegration of 
software components into applications. flFor a detailed 
discussion of COM and OLE, see Kraig Brcjckschmidt , Inside 
OLE, Second Edition, Microsoft Press, Rddmond, Wash. 
(1995)). 

Thus, when considered as a whole, Hinsori expressly taught 
that either COM or CORB^ was used with an opejrating system to 
implement the invention, i Accordingly/ the stjatement concerning 
"other modules" by Hinson- provides no basis irfor . replacing the 



system of Hinson with a- conrpletely different 



system. Further, 



the events that are fired; by the publisher in Hinson are based 



The rejection has 
firing events 



on something associated. with the publisher, 
failed to cite any teaching or suggestion of 
based on anything that happens in object store 142 of Hinson. 
Accordingly, the modification changes the priinciples of 
operation of Hinson. The MPEP indicates that such a change 
means that a prima facie obviousness rejection has not been 
made. ' } ' 

The information relied upon in LeBlanc [fails to overcome 
the shortcomings noted above. Accordingly, the combination of 
references fails to suggest or disclose the miethod of Claim l. 
Applicants request reconsideration and withdrawal of the 
obviousness rejection of each of Claims 1, 26\ arid 40. 

Claims 2 to 6 and 8 to 11 depend from Cl^im 1 and so 



distinguish over the combination for at least 
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as given above for Claim 1. Further, for example, the 
"bitniask" of Claim 6 haa been reduced to a gistj. "Bitmask" or 
"bit mask" does not appear in Hinson and so Hinson fails to 
suggest or describe the combination event source interface of 
Claim 6. Applicants respectfull^ request reconsideration and 
withdrawal of the obviousness rejection of each; of Claims 2 to 
6 and 8 to 11. i ' 

! I ; 

With respect to the obviousness rejection of Claim 12, the 
Examiner relies upon the rejection of Claims ll and 6. However, 

i ! ! 

Claim 12 recites "wherein said event type is [included in a 
plurality of event types includii^g an instance event, a class 
event, an association event - 



. J " Neither Claim 1 nor Claim S 

includes this plurality and so the rejection istated: 

' ' I 

■ I 

Hinson further teaches .event types 'incpluding an 
instance event (line 58 column 1 to line 10 column 2 , . . 
an associate event and a combination of levents (line 58 
column 1 to line 10 column 2) - 

Applicants respectfully note "event typ^" as interpreted 

in this part of the rejection is 'different fi!om!the 

1 I i 

interpretation of event type in the rejection of claim 1, which 

I ' ' 

is used to form the basis of the jrejection of Claim 6. See 

also the rejection of Claim 5 that utilizes but | yet another 



different definition. This demonstrates yet 



further that the 



definition selected changes depending on the pairt of the claim 

and the claim considered. I 

I 
I 

Further, Col. 1, line 58 tojCol, 
stated: 



2 line JlOjof Hinson 



I. 



In accordance with object-oriented programming 
principles, the component a^jplication is a collection of 
object classes which each model real wor;ld!or abstract 
items by combining data to i^epresent thq item's properties 
with functions to represent [the item's fiunctionality • More 
specifically, an object is a!n instance o*f a programmer- 
defined type referred to as a class, whijch | exhibits the 
characteristics of data encapsulation, p^olymorphism and 
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inheritance. Data encapsulation refers to the combining of 
data (also referred, to as properties of I ani object) with 
methods that operate on the data {also referred to as 
member functions ofl an object) into a unitary software 
component (i.e., the object), such that j the object hides 
its internal composition, structure and {operation and 
exposes its functicinality to client programs that utilize 
the object only through one or more interfaces. An 
interface of the ot|ject is a group of semantically related 
member functions of the object- In other words, the client 
programs do not access the object's data directly, but 
must instead call functions on the object's interfaces to 
operate on the data. I 

i i 

A general description of "object-orientated programming 
principles" as in this portion of Hinson fails to suggest 
anything concerning a pljurality of events or specific event 
within that plurality, jxhere is no basis for taking this prior 
art description in Hinsojn of object-orientated programming 
principles and modifying the invention of Hinson. Accordingly, 
the reliance on this section of Hinson is further evidence that 
the obviousness rejection of Claim 12 is not well founded. The 
above discussion with respect to the combination of references 



with respect to Claim 1 



obviousness rejection of 
With respect to the 



is incorporated herein by reference 



Applicants request recodsideration and withdrawal of the 



Cl^im 12 are 
nc6rporated herein 



Claim 12 . 

obviousness rejections ! of independent 
Claims 13, 24, 37, 38/ 41, and 42, each clain; includes at least 
the limitation as discussed above with respect to Claim 12 
Therefore, the above remarks with respect to 
applicable for each of these claims and are i 
by reference. Applicants respectfully request ^reconsideration 
and withdrawal of the obviousness rejection of each of Claims 
13, 24, 37, 38, 41, and 42. 

Claims 15 to 19 have been cancelled and 
obviousness rejections moot. 

Claims 27 to 31 and 33 to 3 6 depended frpmj Claim 26 and so 
distinguish over the prior art for at least tlhejsame reasons as 



so ' render the 
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Claim 26- Applicants respectfully request reconsideration and 
withdrawal of the obviousness rejection of eachj of Claims 27 to 
31 and 33 to 36. j 

Claims 1 to 6, 8 to 13, 24, 26 to 31, 33 to 38, and 40 to 
42 remain in the application. Claims l, I2,jl3, 24, 26, 37, 
38, and 40 are amended. Claims 15 to 19 are | cahcelled. Claims 
1, 14, 20 to 23, 25, 32^ 39, and 43 were pre^J-iously canceled. 
For the foregoing reasons. Applicants respectfully request 
allowance of all pending claims- If the Examiner has any 
questions relating to the above, the Examinef: is respectfully 



requested to telephone the undersigned Attorney 
Applicant (s) . i 



for 
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abstract data type 



(definition) 



Definition: A set of data values and associated operations tliat are precisely specified independent of any 
particular implementation. i 



Also knoM^ as ADT. 



Specialization 0- is a kind of roe.) i 
dictionary^ stacks queue, p riori ty qiieue^ set^ bag, \ 

See also daia structure. \ 

Note: Since the data values and operations are defined with mathematical precisibn, mther than as an 
implementation in a computer language, we may reason about effects of the operdtioris, relations to Other 
abstract data types, whether a program implements the data type, etc. j 

i I 

One of the simplest abstract data types is the stacL The operations newQ, push(v, [S), top(S). and popClff(S) may 
be defined with axiomatic semantics as following. ; 



1. newQ returns a slack 

2. popqff(push(v,s)) = s . : 

3. top(push(v, S))-v ; • 

where Sis a stack and visa value. (The usual pop operation is a combination of top. to return the top value, 
and popOff, to remove the top value.) Contrast this with the axiomatic semantics definition of a s§f, a 
dictionary, or a queue. I 

From these axioms, one may define equality between stacks, define a pop fiinctioniwhich returns the top value 
in a non-empty stack, etc. For instance, the predicate isEmpty(S) may be added and defined with the following 
additional axioms. ' 

4. isEmpiy(new0) ^ true [ 

5. isEmpty(push(v, S)) = false . 
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